Distributed process control systems, like those used in chemical, petroleum or other processes, typically include one or more process controllers communicatively coupled to one or more field devices via analog, digital or combined analog and digital buses. The field devices, which may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure, level and flow rate sensors), are located within the process environment and perform process functions such as opening or closing valves, measuring process parameters, etc. Intelligent (or “smart”) field devices, such as the field devices conforming to the well-known Fieldbus protocols, like the FOUNDATION® Fieldbus protocol, may also perform control calculations, alarming functions, and other control functions commonly implemented within the controller. The process controllers, which are also typically located within the plant environment, receive signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices and execute a controller application that runs, for example, different control modules that make process control decisions, generate control signals based on the received information and coordinate with the control modules or blocks being executed in the field devices, such as HART® and Fieldbus field devices. The control modules in the controller send the control signals over the communication lines to the field devices to thereby control the operation of the process.
Information from the field devices and the controller is usually made available over a data highway to one or more other hardware devices, such as operator workstations, personal computers, data historians, report generators, centralized databases, etc., typically placed in control rooms or other locations away from the harsher plant environment. These hardware devices execute applications that may, for example, enable an operator to perform functions with respect to the process, such as changing settings of the process control routine, modifying the operation of the control modules within the controller or the field devices, viewing the current state of the process, viewing alarms generated by field devices and controllers, simulating the operation of the process for the purpose of training personnel or testing the process control software, keeping and updating a configuration database, etc.
As an example, the DeltaV™ control system, sold by Emerson Process Management includes multiple applications stored within and executed by different devices located at diverse places within a process network that may be located at a single facility or networked across several facilities or process control plants. A configuration application, which resides in one or more operator workstations, enables users to create or change process control modules and download these process control modules via a data highway to dedicated distributed controllers. Typically, these control modules are made up of communicatively interconnected function blocks that are objects in an object oriented programming protocol and perform functions within the control scheme based on inputs thereto and provide outputs to other function blocks within the control scheme. The configuration application may also allow a designer to create or change operator interfaces or human-machine interfaces (HMIs) which are used by a viewing application to display data to an operator and to enable the operator to change settings, such as set points, within the process control routine. Each dedicated controller and, in some cases, one or more field devices, store and execute a controller application that runs the control modules assigned and downloaded thereto to implement actual process control functionality. The viewing applications, which may be executed on one or more operator workstations, receive data from the controller application via the data highway and display this data to process control system designers, operators, or users using the user interfaces, and may provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, a maintenance view, etc. A data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided across the data highway while a configuration database application may run in a still further computer attached to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.
As the number and type of control and support applications used in a process control environment have increased, different graphical display applications have been provided to enable users to effectively configure, monitor, and use these applications. For example, graphical display applications have been used to support control configuration applications to enable a configuration engineer to graphically create control programs to be downloaded to the control devices within a process plant. Additionally, graphical display applications have been used to enable control operators to view the current process conditions of the process plant (or areas of the process plant), to supervise and manipulate process control functions, to monitor process-level alarms, etc. Other graphical display applications enable maintenance personnel to view the functioning state of hardware devices and various areas within the process plant, while yet other graphical display applications permit engineers to simulate the operation of the process plant.
A configuration engineer may use a graphical display creation application to create one or more displays for operators, maintenance personnel, etc., within the process plant by selecting and building display objects in the display creation application. These displays are typically implemented on a system-wide basis in one or more of the workstations and provide preconfigured displays to the operator and maintenance personnel regarding the operating state of the control system or the devices within the plant. In larger process plants, displays may be specific to a certain portion of the plant or a certain functional area. In general, the displays take the form of alarming displays that receive and display alarms generated by controllers or devices within the process plant, control displays indicating the operating state of the controllers and other devices within the process plant, maintenance displays indicating the functioning state of the devices within the process plant, etc. Further, these displays are typically preconfigured to display information or data received from the process control modules or the devices within the process plant. For example, a graphic on the display screen may change in real-time to illustrate that a tank is half full or that the position of a valve has changed, or a numerical indictor included in the graphic display may be updated according to the flow measured by a flow sensor or the temperature of a reactor.
Historically, real-time process control data to which displays had access was limited primarily to controllers. In other words, prior to the introduction of intelligence to field devices, configuration engineers did not develop displays capable of automatically displaying diagnostic or alarm data originated from field devices. Of course, intelligent field devices today are an important source of process control data, and retrieving, displaying, and applying information from intelligent field devices is instrumental in operating and diagnosing control operations in a process plant.
Although intelligent field devices have been available for a number of years, configuration engineers continue to face numerous challenges in efficiently incorporating information from such devices into displays. Configuration engineers typically dedicate a significant amount of time and effort to developing screens specific to process areas and operational tasks associated with these areas, and budget considerations often do not permit re-development (or even modification) of displays to accommodate new sources of information. Moreover, configuration engineers often develop displays separately from control strategies. At the time when a display is being developed for a particular control strategy, the configuration engineer may not yet know which devices the control strategy will use, or whether these devices will be intelligent. Many displays, some of which may be regarded as legacy displays, thus continue to have hard-coded process parameters and graphical components.
In many process plants, control strategies and field devices are typically represented as separate objects in a process control system. Control strategy objects and device objects have respective distinct tags, alarms, faceplates, and other attributes. Thus, with the introduction of intelligent field devices, the number of objects in a typical process control system has increased dramatically. Although these objects provide operators with a wealth of useful information, the number of such objects has increased the complexity of the tasks needed to be completed by operators and configuration engineers. Thus, many users must evaluate the impact of intelligent field devices on their existing work practices and possibly define new practices to effectively use these new sources of information. Some facilities accordingly have been reluctant to dedicate resources to redefine the existing practices, and instead have chosen to supervise process plant operations without the aid of information from intelligent field devices. In particular, these facilities continue to use displays that do not reflect diagnostic, alarm, and other process data available from intelligent field devices.
On the other hand, incorporation of information from intelligent field devices into displays sometimes has the undesired effect of frustrating users by the amount of detail and complexity of depicted information. For example, an object corresponding to a certain control strategy, along with objects corresponding to devices used by the control strategy, may provide an overwhelming amount of information that some users will perceive as noise. Moreover, displaying all of the available information on a display also creates undesired clutter, and further worsens user experience. It is thus common to logically group the available information under various user menu options.
In any event, as a result of these factors, the number and type of control and support applications used in a process control environment have increased, and in particular, different graphical display applications have been provided to enable users to effectively configure and use these applications. For example, graphical display applications have been used to support control configuration applications to enable a configuration engineer to graphically create control programs to be downloaded to the control devices within a process plant. Additionally, graphical display applications have been used to enable control operators to view the current functioning of the process plant, or areas of the process plant, to enable maintenance personnel to view the state of hardware devices within the process plant, to enable simulation of the process plant, etc. However, these graphical display applications have, in the past, been separately created as part of the specific applications with which they are associated, and thus are generally limited in usefulness to the specific process function for which they were created. For example, it is difficult, if not impossible, to use a graphical program created to support a control operator in a context involving maintenance, configuration, or simulation functions.
Further, the existing applications typically require a large number of clicks of selections to reach a desired menu item in a display. In particular, operators or maintenance personnel interested in “drilling down” into a module often have to activate numerous menus, review and respond to multiple dialogues, etc. In many cases, controls for triggering tasks are not organized in an intuitive manner, and accordingly require a significant amount of time to master.
In another case, the ever-increasing number of command options and features continues to make process control design, configuration, and management more complex. A typical user often sees numerous controls and menu items on the screen whereas only a relatively small subset of these controls or menu items is applicable to the task the user performing.
During configuration, a display creation application may have template graphical display items, such as tanks, valves, sensors, operator control buttons like slide bars, on/off switches, etc. which may be placed on a screen in any desired configuration to create an operator display, maintenance display and the like. When placed onto the screen, individual graphic items may be interconnected on the screen in a manner that provides some information or display of the inner-workings of the process plant to different users. To animate the graphic display, the display creator manually ties each of the graphical items to data generated within the process plant, such as data measured by sensors or indicative of valve positions, etc. by specifying a communication link between the graphic item and the relevant data source within the process plant. This process is tedious, time consuming and may be fraught with error and additionally requires significant programming knowledge and knowledge of the plant configuration. Moreover, once a display is created, it remains static in its configuration and layout and thus difficult, if not impossible to change.
Moreover, graphics are typically defined separately from the control strategies, and one graphics display may often be used with multiple different control modules. Because a wide variety of variations of graphics are expected in graphics displays, it is necessary to design a graphics configuration system, using special forms, that specifies which variations are to be allowed or enabled with override structures in each of the graphics displays. These variations include, for example, specifying changes such as allowing the user to define the rotation for part of the item, select what strings and variables must be shown in the display and which ones are optional, etc. Without this up front design, the graphic displays cannot even have small changes made thereto during run-time of the plant. Unfortunately, a configuration system that attempts to design or pre-specify the allowable changes in all graphics displays quickly becomes unusable, as variations on graphics items in a display is very common. As a result, maintaining graphics cost effectively is an ongoing problem within control systems, and is only exacerbated when the step of maintaining graphics must be coordinated with the changes being made to control module classes used in the control configuration system.
As an example, operator displays used to monitor and control process plants are defined in a programming environment, and once complete, are deployed for use by operators. If changes are required to a deployed display, the changes are implemented in the programming environment and the display is then redeployed. Although cumbersome, proper design of operator displays is critical to the safe operation of a process plant. Thus operators are not typically allowed to change the displays themselves. In addition, most operators do not have the training required to be able to program new displays.
However, as noted above, process graphics require lengthy and costly engineering time to configure. The displays are often designed based on the piping and instrument diagrams, ensuring that all of the measurements and controls are represented for the operator. While some displays may be programmed for known tasks such as plant startups and shutdowns, it is impractical to create one-off displays that serve all of the potential specific purposes expected to be performed by a particular user or to customize a display for particular task performed by a single user. Moreover, the creation of task specific displays requires collaboration between the engineers and operations personnel, which may not be practical during the configuration effort which is when the displays are being defined. If there is no display defined for a particular task, the operator must navigate across the displays that have the needed information, in order to properly monitor and operate the process. This operation is disruptive to the operator and can increase the risk of operator errors, due to needing to memorize the information on the other displays.
Moreover, the navigation activities that the operator uses to change between the displays available to the operator is typically programmed into the displays. While it is typical to program multiple direct display connections within the operator displays, these display connections also typically follow the piping and instrument diagrams of the plant which may not be the manner in which a particular operator needs to navigate between displays. In order to ensure that the operator can quickly access whatever displays are needed, these displays may provide or add numerous, such as 30 or more, display access points on a display that enable a user to easily access other displays. However, again, the user must be familiar enough with the display to be able to navigate quickly to the correct display to find the information the operator needs.